As you start writing more complex shell scripts, you'll start finding commands that don't work in all the shells. At this point, you'll have three options.
One option is to restrict yourself to the commands that work in all the shells. Another option is to determine which shell you're in and then use conditional statements to allow you to take advantage of the shell you're currently using. Your last alternative is to let the script specify which shell to use.
As long as you're not doing anything fancy, you can limit yourself to the commands that are common to all the shells. Obviously, all the commands in your path will execute the same way whether you're in a shell or not.
However, once you start using variables or other so-called advanced
features in your scripts, you start running into problems. In
the Bourne shell, you can set a variable to a value with a statement
like
variable=value
To do the same thing in the C shell, you need the statement
set variable=value
Another problem with trying to limit yourself to a restricted subset of features is that you can spend too much time verifying that your scripts work in all the shells. As you can see, this really isn't a viable solution.
If you want to take advantage of more features in the shell, you might decide to write some code to determine which shell is running. Then your script can execute code that exploits that particular shell.
For example, if you need to tell whether you're in the Bourne
or Korn shell, you can execute the following statements:
if [ $RANDOM == $RANDOM]
then
echo "Bourne shell"
else
echo "Korn shell"
fi
Here, all we did was to check if the value of the shell variable RANDOM equals itself. In the Korn shell, the RANDOM shell variable is tied to a random number generator that changes values (between 0 and 32767) each time you access it. The Bourne shell doesn't have the random number generator feature, so the value of RANDOM will be the same on each usage, unless you actively change it.
There are two big drawbacks to this technique: First, you must find a way to differentiate between all the shells on your system. You must also write more code than is strictly necessary, since your script is supposedly going to run under multiple shells. We won't even mention that your scripts could break if you install a new shell, like bash or tcsh.
The best solution is to let the script itself specify the shell
to use. This way, the shell will execute correctly no matter what
shell you're using. To do so, the first line of your script should
be in the form
#! /path/shell [options]
The first character is a #, telling the shell that the line is a comment. Next comes an !, which tells Solaris that you're going to specify which shell to use. Then comes the name of the shell, including its path. You may also follow the shell with any options you want for the shell.
For example, suppose you want to run a script using the C shell.
To do so, you might use this line to start your script:
#! /usr/bin/csh -f
The best part of this technique is that you don't have to use only shells to process your scripts. Many other programs, like perl, also work well as script languages. If you don't know whether a program will work as a script language, try it and see.
If you're writing a C shell script, you may want to use the -f option. A "fast start" option tells the C shell not to process your .login or .cshrc files, allowing the script to run more quickly. It has the added benefit of preventing your script from using your customized environment, to a certain extent. Now when you give a shell script to your colleagues, there's a better chance of it working in their environments.
[Return to Index for Inside Solaris - June 1996 Issue]
Copyright (c) 1996 The Cobb Group, a division of Ziff-Davis Publishing Company. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of Ziff-Davis Publishing Company is prohibited. The Cobb Group and The Cobb Group logo are trademarks of Ziff-Davis Publishing Company.
1-800-223-8720